Summary

Major version (v6.0) reworking how processing plugins are stored and served.
Plugin code, schemas, metadata and access grants move fully into
@data-fair/registry; processings
becomes stateless with respect to plugin content.

Previously plugins lived on a persistent volume at dataDir/plugins/{id} with
sibling -access.json / -config.json / -metadata.json files, installed via a
superadmin-only POST /api/v1/plugins (npm pack + npm install). Now the API
and worker pull pre-built tarballs from the registry on demand into an ephemeral
per-container cache via registry's lib-node.

See docs/architecture/v6-registry-integration.md for the full design.

Changes

Registry integration

• API and worker resolve plugins through ensureArtefact (lib-node-registry),
  downloading + extracting tarballs into ${tmpDir}/registry-cache on cache miss.
• Registry is the single source of truth for plugin code, schemas, public/private
  flag, access grants and metadata — no mongo collection mirrors plugin state.
• Plugin access control is delegated to the registry: the owner account is
  passed on every call, and a 403/404 from the registry surfaces directly,
  replacing the explicit access check in the create/update endpoints.
• New shared/plugin-load.ts resolves a plugin entry point from
  package.json#main (supports pre-built JS or Node type-stripped TS).
• New GET /processings/:id/plugin-config-schema reads processing-config-schema.json
  from the cached tarball (same convention as v5).

Removed

• POST/GET/PUT/DELETE /api/v1/plugins endpoints and the on-disk plugin dir.
• The plugins-registry router.
• The UI admin "Plugins" page; the "create processing" picker now calls the
  registry directly (mounted at /registry on the same domain).

Broken-plugin processings UX

When a plugin is no longer available (deleted from the registry or access
revoked), processings using it are handled gracefully instead of erroring out:

• Worker logs a friendly message on a run whose plugin is unavailable.
• UI shows a "Plugin unavailable" badge (renamed from "Deleted") with a tooltip,
  an edit-page banner, and hides the form / exec / duplicate / change-owner
  actions while keeping the processing readable and deletable.

Config

• New required privateRegistryUrl and secretKeys.registry
  (PRIVATE_REGISTRY_URL, SECRET_REGISTRY).
• dataDir is now optional — when set it implies the legacy plugins volume is
  mounted (read-only, transitional; dropped in v7.0).

Migration

• upgrade/5.2.0/01-publish-plugins-to-registry.ts — first-boot migration:
  re-tars each plugin dir (with node_modules) and uploads it to the registry,
  along with metadata and access grants. Fails fast on orphan processings.

Testing

• New API/e2e specs: branch-plugin, broken-plugin, available-plugin.
• New test support helpers: tests/support/registry.ts, data-fair.ts,
  PATCH /test-env/raw-processing/:id for invalid-state setups.
• Removed obsolete plugins/install and plugins/registry specs.

Breaking changes

• The legacy plugins volume and /api/v1/plugins API are gone. Deployments must
  configure privateRegistryUrl + SECRET_REGISTRY and run the 5.2.0 upgrade
  scripts. The legacy volume may stay mounted read-only through v6.0 for
  deprecated per-instance plugin-config; both are removed in v7.0.